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BACKGROUND OF THE INVENTION 

RELATED APPLICATION 

This application claims the benefit of co-pending United States Provisional Patent 
Application No. 60/295,900 filed June 4, 2001, co-pending United States Non-Provisional 

Patent Application No. filed on , co-pending United 

States Provisional Patent Application No. 60/295, 987 filed on June 4, 2001, and co-pending 

United States Non-Provisional Patent Application No. filed on 

, and claiming priority to the above mentioned Non-Provisional Applications 

the disclosures of which are hereby incorporated by references. 

1. FIELD OF THE INVENTION 

The present invention relates to file systems, and in particular to a method for 
resolving a conflict between parallel user changes to two synchronized trees of folders and 
files. 

Portions of the disclosure of this patent document contain material that is subject to 
copyright protection. The copyright owner has no objection to the facsimile reproduction by 
anyone of the patent document or the patent disclosure as it appears in the Patent and 
Trademark Office file or records, but otherwise reserves all rights whatsoever. 
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2. BACKGROUND ART 



A way to organize files and folders of a user on a computer is by arranging them in a 
structure commonly known as a tree. Oftentimes, files and folders are changed. When this 
happens, a new tree is generated. It is helpful sometimes to find and reconcile differences 
between the old and new trees. Reconciling differences could lead to conflict in changes that 
require indication as to which conflicting takes precedence. Resolving these conflicting 
changes currently is very difficult, as will be further explained below. Before discussing this 
problem, an overview of a tree data structure is provided. 

Tree Data Structure 

A tree data structure is illustrated in Figure 1 . The apex 100 of the tree is commonly 
called the root. The root is usually a folder that contains all other sub-folders and files of a 
user. The root is the starting location of all folders and files of a computer user firom where 
links spread out like branches of a tree to other sub-folders and files. 

The nodes of the tree (i.e., the actual files) are denoted by parent, child, leaf, and non- 
leaf locations or nodes. A parent is any node that has a branch leading down to one or more 
lower nodes, hi Figure 1, root 100 is one example of a parent. A child is any node that has a 
branch leading up to a higher node. Referring back to Figure 1, all nodes except the root is a 
child node. This child node category can be further segregated into left and right child 
depending upon the location of the child node with respect to its parent. Node 101 is a right 
child node, while node 102 is a left child node of parent node 103. A leaf node is any node 
that does not have any branches leading to lower levels in the tree. All nodes at the bottom 
most level of the tree (for example, 104, 105, and 106) are leaf nodes. In contrast, all other 
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nodes are categorized as non-leaf nodes as they have a child node under them (for example, 
100). 

Tree Modification 

When a user makes changes to the folders and files, for instance by deleting or adding 
a file or changing its contents, these changes have to be correctly incoiporated into the tree. 
Typically, a new tree is generated every time a change is made. This new tree is then 
compared to the old tree, and all necessary changes are reconciled to create one updated tree. 
Reconciling differences could lead to conflict in changes that require indication as to which 
conflicting change should win. This requires that the old state has to be remembered and 
compared with the new state in order to resolve any conflicting changes, which is wasteful of 
resources. 

File Tree Conflict Processor 

Li order to resolve any conflicting changes between an old and a new file tree, the two 
trees have to be compared. A utility, commonly called a file tree comparator, compares the 
two file tree descriptions and generates a sequenced log of changes that transforms the old 
tree to a new tree. A complete description of one file tree comparator is contained in co- 
pending provisional U.S. patent application 'Tile Tree Comparator", Sr. No. 60/ 296, 065 
filed on June 4, 2001, and co-pending non-provisional U.S. patent appUcation "File Tree 

Comparator", Sr. No. filed on , and assigned to the 

assignee of this patent. 

After the changes have been recorded, another utility, commonly known as a 
reconciler, takes in as its input the log of changes (if one is available) firom both the old and 
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the new file trees and reconciles any changes that have occurred since the last 
synchronization. A complete description of one file tree reconciler is contained in co- 
pending U.S. patent application "File Tree Reconciler", Sr. No. 60/ 295, 987 filed on June 4, 

2001, and co-pending U.S. patent application "File Tree Reconciler", Sr. No. 

5 filed on , and assigned to the assignee of this patent application. 

When reconciling parallel user changes to two synchronized trees of folders and files, 
conflicting changes may be encountered that require indication as to which conflicting 
change takes precedence. These conflicting changes are handled by another utility commonly 
1 0 called a conflict processor. Some conflicting changes cannot be resolved independently, and 
those entangled conflicts have to be combined into one to be presented to the user as a single 
D conflict. After the user indicates the winner of the conflict, the winning operations need to be 

Id applied to the file tree with which they are in conflict. 

m 

I'" 15 There are several commercially available conflict processors that find conflicting 

fi I changes in two file tree structures. One file tree conflict processor is called Xfiles. Xfiles 

allows comparing, reconcihng any changes, reconciUng any conflicting changes, and merging 
two file trees over a network, hi operation, Xfiles compares and merges the two file tree 
versions using a cUent/server program (graphical user interface on the client) that traverses 
20 the file trees and reports any files that are missing on the server or client machines, are 
different, or are conflicting with each other. 

The main drawback with Xfiles is that the entire tree has to be traversed in order to 
find any conflicting changes to be reported to the user. Many trees are very large, in which 
25 case a substantial amount of time may be wasted traversing large portions of the tree that are 
not modified. Moreover, if the network connection is slow, or network traffic high, Xfiles 
becomes prohibitively wasteful of resources. A second drawback associated with Xfiles is 
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that those conflicting changes have to be manually removed by the user. This compels the 
user to have a thorough knowledge of the entire file tree, and of all the changes made to it. 

Another file tree conflict processor, termed Teamware, includes methods for finding 
differences in file trees, with the assumption that the file trees are of a special type - 
containing only SCCS folders and files - that are directly annotative. Using Teamware, 
developers may each be assigned a separate sub-directory of a single root directory 
designated as the parent workspace for a current project. The parent workspace contains the 
original copies of each project file and records of each set of changes to each file. 

The developers obtain copies of project files for reading and editing purposes within 
their individual workspaces, and to record any modifications they make in the central location 
later on. A locking mechanism in SCCS prevents two developers firom checking out the 
same file for editing at the smie time. There are several drawbacks with Teamware, which 
include detecting file tree conflicting changes based on modification times rather than on 
change logs. Teamware is restricted further because it only works on SCCS folders and files, 
so, it has no apphcation to most file tree systems. 

Another file tree conflict processor is called Unison. Unison is a file synchronization 
tool for Unix and Windows operating systems. It allows two replicas of a collection of files, 
folders, or directories to be stored on different hosts or different disks on the same host, 
modified separately, and then brought up to date by propagating the changes in each rephca 
to the other. Unison sends firom one side (server or cUent) to the other the entire log, and 
makes the receiving side responsible for finding any conflicting changes in the files, folders, 
and directories of both sides. This system works well only because the utihty has an 
indefinitely growing version log for each synced file, which is pruned only when all known 
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synchronizers have seen the pruned versions. There is a time limit (usually a month) when 
the utiUty abandons files that have not been synced in order to prune the size of the log. 

There are several drawbacks with this utility. A log for the entire file tree is sent 
across. If the file tree is large, the time involved in transmitting the log for the entire file tree 
can be time consuming, especially if the network connection is slow, or the network is highly 
congested. Moreover, a file not in use beyond the time limit is automatically abandoned by 
the log. If a user attempts to m^Jce certain changes to it, they may not be reflected in the log 
that is sent across to the other side. If these changes conflict, the user will be unaware of this 
causing synchronization problems. Furthermore, the conflict processor utility simply gives a 
list of all conflicts to the user, who has to manually resolve all conflicts. This compels the 
user to have a thorough knowledge of the entire file tree, and of all the changes made to it. 
This makes use of the tool difficult and unyielding. 
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SUMMARY OF THE INVENTION 



The embodiments of the present invention provide a method for resolving conflicting 
changes encountered when reconciUng parallel user changes to two synchronized trees of 
folders and files. According to one embodiment each synchronized tree of folders and files 
may reside on a client and server respectively. According to one embodiment, these conflicts 
require user indication as to which conflict takes precedent. According to one embodiment, 
these conflicts are presented to the user as an interface. 

According to another embodiment, since certain conflicts cannot be resolved 
independently, they are combined into one, and presented to the user as a single conflict. 
According to yet another embodiment, after the user has indicated which operations are the 
winners of all or some of the conflicts, the winning operations are applied to the file tree with 
which they are in conflict. This file tree can be on either the client or the server. 
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BRIEF DESCRIPTION OF THE DRAWINGS 



These and other features, aspects and advantages of the present invention will become 
better understood with regard to the following description, appended claims and 
accompanying drawings where: 

Figure 1 is an illustration of a file tree structure. 

Figure 2 is a flowchart of a system which processes file trees. 

Figure 3 is a flowchart of one embodiment of the present invention. 

Figixre 4 is a flowchart of another embodiment of the present invention. 

Figure 5 is a flowchart where a conflict is removed from the conflict list once it is 
resolved by the conflict processor. 

Figure 6 is a flowchart of another embodiment of the present invention. 

Figure 7 is a flowchart of another embodiment of the present invention. 

Figure 8 is a flowchart of another embodiment of the present invention. 

Figure 9 is an illustration of an embodiment of a computer execution environment. 

Figure 10 is a flowchart illustrating an initial synchronization between a client and a 

server. 
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Figure 1 1 is a flowchart illustrating a conflict encountered by a file tree conflict 
processor. 
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DETAILED DESCRIPTION OF THE INVENTION 

The embodiments of the present invention are a file tree conflict processor. In the 
following description, numerous specific details are set forth to provide a more thorough 
5 description of embodiments of the invention. It will be apparent, however, to one skilled in 
the art, that the embodiments of the present invention may be practiced without these specific 
details. In other instances, well known features have not been described in detail so as not to 
obscure the invention. 

10 File Tree Conflict Processor 

^ A file tree conflict processor operates at the end of a system which processes file 

;1 trees. The system is shown in Figure 2. At block 200 the file tree comparator compares the 

I ! i) 

n file trees. At block 210, the file tree change reconciler reconciles any changes to the file 

W 1 5 trees. At block 220, the file tree conflict processor processes any conflicts that may arise 
during the reconciliation operation above. 

ru 

p One embodiment of the present invention is shown in Figure 3. It shows in more 

detail the process that might occur at block 220 in Figure 2 above. At block 300, a conflict is 
20 encountered while comparing two file tree structures. At block 3 10, the conflict is put in a 
conflict list. At block 320, the processor checks for any more conflicting changes in the two 
file trees. If there are more conflicts found, they are put in the fist (block 320), else at block 
330 the conflict list is displayed to the user. 

25 Figure 11 is a flowchart that illustrates an example of a conflict that may be 

encountered by the file tree conflict processor. At block 11 00, a change is made on the cUent 
side, for example a replace operation. At block 1110, this change is made in a directory, for 
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example Status.html, and at block 1 120, the file or path where the change is made is noted, 
for example contents: <!doctype html pubhc "-//w3c//dtd html [..]. Similarly, a change can 
be made on the server side. It must be noted here that the change on the serer side is made 
independent of the change on the client side. Li other words, the server side change can be 
made simultaneously as the client side change, or can be made at a different time. 

A server side change is seen at block 1 130. This change may be for example a 
replace operation. At block 1 140, this change is made in a directory, for example 
Status.html, and at block 1 150, the file or path where the change is made is noted, for 
example contents: <!doctype html semi-private "-//w3c//dtd html [..]. The path of changes 
made on the chent and server sides are different, and after a synchronization process of the 
client and the server, the file tree conflict processor encounters this difference. The 
resolution of the difference is explained in other embodiments of the invention below. 

An example of a server's version of its "briefcase index tree" presuming that it 
resolves the conflict mentioned above in favor of the server after a synchronization operation 
may look like: 
Conflicts(l): 
Conflict 1: 

CUent changes: 1 

ContentChange: Replace 

path: Status.html 

contents: <!doctype html public *V/w3c// dtd html [..] 
Server changes: 1 
ContentChange: Replace 
path: Status.html 

contents: <!doctype html semi-private "-//w3c//dtd html [,.] 
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We notice in the example above that the server has not appHed the conflicting client 
change as its stored signature, but has instead reflected the content as changed by the server. 
The objects to check for the conflict mentioned above may look like: 

MappedContentLidex 

path = /home/usemame/master/ 

Contentlndex 

children(l): 
Contentlndex 

path = Status.html 

content signature: OAhokpmqGRLOlalcS. 

Another embodiment of the present invention is shown in Figure 4. At block 400, the 
conflict processor obtains a conflict list. At block 410, the conflict processor examines the 
conflicts in the conflict hst. At block 420, the conflict processor checks the conflict Ust if 
there are more than one conflict that camot be resolved independently, and can be combined 
to form a single conflict. If there are conflicts that cannot be resolved independently and can 
be combined to form a single conflict, the conflict processor combines those conflicts into a 
single conflict at block 430 before displaying the Ust to the user at block 440. If on the other 
hand, all conflicts in the conflict list can be resolved independently or there are no conflicts 
that can be combined to form a single conflict, the conflict processor displays the Ust to the 
user at block 440. 

Figure 5 shows another embodiment of the present invention where a conflict is 
removed from the conflict Ust once it is resolved by the conflict processor. At block 500, the 
conflict list is examined by the conflict processor. At block 510, the conflict processor 
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obtains user suggestions for the conflict in the conflict hst. At block 520, the conflict 
processor checks to see if the winning operation is a server operation. If it is, then at block 
530 the conflict is handled. At block 540, the conflict is removed from the conflict list. If at 
block 520, the wining operation is not a server operation, then at block 550 it checks to see if 
5 the winning operation is a cUent operation. If the operation is not a cHent operation, then at 
block 560, it submits an error message to the user. If on the other hand, block 550 is a cUent 
operation, then the processor handles the conflict at block 530 before removing the conflict 
from the conflict list at block 540. 

Figure 6 shows another embodiment of the present invention where the winning 
operations, based on the choice made by the user, are appUed to the file tree which has the 
conflicts. At block 600, the first conflict in the conflict Hst is examined by the conflict 
processor. At block 601, the processor checks to see if the conflict has a user suggested 
resolution. If the conflict is not marked by a user suggestion, then at block 602 the processor 
checks for the next conflict in the conflict list. At block 602, if there is another conflict in the 
conflict fist, it is examined at block 603 before going back to block 601. On the other hand, 
if at block 602 there is no more conflicts in the conflict list, then the processor checks at 
block 604 if there are any unresolved conflicts in the conflict Ust. If there are unresolved 
conflicts in the conflict hst, then at block 605 the conflict processor waits for a valid user 
suggestion for the conflicts. 

If block 601 has a user suggested resolution, the conflict processor checks at block 
607 to see if the server operations should win. If the server operations are the winners of the 
conflict, then at block 608 the operations are translated back up the conflict Ust across all 
25 previous server operations. At block 609, the operations are translated dovm the conflict list 
across all client operations. At block 610, the operation is replaced in the preamble along 
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with the translation. At block 61 1 the conflict is marked as resolved, and the conflict 
processor goes back to block 602 to check for another conflict in the conflict list. 

If at block 607 the server operations do not win, then the processor checks at block 
5 612 if the chent operations should win. If the client operations are the winners of the 
conflict, then at block 613 the conflicts are translated back up the conflict list across all 
previous cUent operations. At block 614, the operations are translated down the conflict list 
across all server operations. At block 615, the cUent operation is effected in the server 
filesystem. At block 616, the conflict processor checks if the operation is successful. If it is 
1 0 not successful, then the conflict processor goes back to block 615. On the other hand, if the 
M= operation is a success, then at block 617 the client operation is effected in the s-bit. At block 
O 61 8 the server operation is removed from the preamble, and at block 6 1 1 the conflict is 

jil marked as resolved before the conflict processor goes to fetch the next conflict at block 602. 
^ If the block 612 the client operations do not win, then the conflict processor goes to block 

' 1 5 605 and awaits a valid user suggestion for the conflict. 
fu 

One example of translation here means that if the crossed operations are a rename or a 
^ reparent of the object of the winning operations, or of one of that object's ancestors in the 

tree, then the winning operations are translated to refer to the object using its new lineage. 

20 This is illustrated in Figure 7, where at block 700, the conflict processor checks to see if the 
crossed operations are a rename or a reparent of the object of the winning operations, or of 
one of that object's ancestors in the tree. If they are, then at block 710, the winning 
operations are translated to refer to the object using its new lineage. If at block 700, the 
crossed operations are not a rename or a reparent of the object of the wiiming operations, or 

25 of one of that object's ancestors in the tree, then it takes action appropriate to the translation 
at block 720. 
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Likewise, translations of winning server operations are queued for transmission to the 
client's filesystem just like the translations of winning client operations are queued for 
transmission to the server's filesystem. This is seen in Figure 8, where at block 800, if the 
translations of the winning operations are server operations, then at block 810 they are 
5 queued for transmission to the client's JBlesystem. If at block 800, the translations of the 
winning operations are not server operations, then the conflict processor checks to see, at 
block 820, if the translations of the winning operations are client operations. If they are, then 
at block 830 the chent operations are queued for transmission to the server's filesystem. 

10 Embodiment of a Computer Execution Environment 

An embodiment of the invention can be implemented as computer software in the 

ill 

\ Jj form of computer readable code executed in a desktop general purpose computmg 

III 

ij environment such as environment 900 illustrated in Figure 9, or in the form of bytecode class 

1 5 files running in such an enviroimient. A keyboard 9 1 0 and mouse 9 1 1 are coupled to a bi- 

f U directional system bus 918. The keyboard and mouse are for introducing user input to a 

[U computer 901 and communicating that user input to processor 913. 

O 

Computer 901 may also include a communication interface 920 coupled to bus 918. 

20 Communication interface 920 provides a two-way data communication coupling via a 

network link 921 to a local network 922. For example, if communication interface 920 is an 
integrated services digital network (ISDN) card or a modem, communication interface 920 
provides a data communication connection to the corresponding type of telephone line, which 
comprises part of network link 921. If communication interface 920 is a local area network 

25 (LAN) card, communication interface 920 provides a data communication connection via 
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network link 921 to a compatible LAN. Wireless links are also possible. In any such 
implementation, communication interface 920 sends and receives electrical, electromagnetic 
or optical signals, which carry digital data streams representing various types of information. 

5 Network link 92 1 typically provides data communication through one or more 

networks to other data devices. For example, network link 921 may provide a connection 
through local network 922 to local server computer 923 or to data equipment operated by ISP 
924. ISP 924 in tum provides data communication services through the world wide packet 
data communication network now commonly referred to as the "Intemet" 925. Local network 
; 1 0 922 and Intemet 925 both use electrical, electromagnetic or optical signals, which carry 
Jf; digital data streams. The signals through the various networks and the signals on network 

i'J. 

r^'" link 921 and through communication interface 920, which carry the digital data to and from 

computer 900, are exemplary forms of carrier waves treuisporting the information. 

* ■!»!• 

15 Processor 913 may reside wholly on client computer 90 1 or wholly on server 926 or 

C3 processor 913 may have its computational power distributed between compixter 901 and 

server 926. In the case where processor 913 resides wholly on server 926, the results of the 
computations performed by processor 913 are transmitted to computer 901 via Intemet 925, 
Intemet Service Provider (ISP) 924, local network 922 and communication interface 920. In 

20 this way, computer 901 is able to display the results of the computation to a user in the form 
of output. Other suitable input devices may be used in addition to, or in place of, the mouse 
901 and keyboard 900. I/O (input/output) unit 909 coupled to bi-directional system bus 908 
represents such VO elements as a printer, A/V (audio/video) I/O, etc. 
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Computer 901 includes a video memory 914, main memory 915 and mass storage 
91 2, all coupled to bi-directional system bus 918 along with keyboard 910, mouse 91 1 and 
processor 913, and file tree conflict processor 927 which reconciles two synchronized tree of 
folders 628 , which is a chent file tree index, and 629, which is a server file tree index. The 
5 two synchronized tree folders 628 and 629 reside on a client and server respectively. 

As with processor 913, in various computing environments, main memory 915 and 
mass storage 912, can reside wholly on server 926 or computer 901, or they may be 
distributed between the two. Examples of systems where processor 913, main memory 915, 
1 0 and mass storage 912 are distributed between computer 901 and server 926 include the thin- 
O client computing architecture developed by Sun Microsystems, Inc., the palm pilot computing 

Yi device, Intemet ready cellular phones, and other Internet computing devices. 

The mass storage 912 may include both fixed and removable media, such as 

ly 

U 1 5 magnetic, optical or magnetic optical storage systems or any other available mass storage 

[y 

O technology. Bus 918 may contain, for example, thirty-two address lines for addressing video 

|?aSf 

memory 914 or main memory 915. The system bus 918 also includes, for example, a 32-bit 
data bus for transferring data between and among the components, such as processor 913, 
main memory 915, video memory 914, and mass storage 912. Altematively, multiplex 
20 data/address lines may be used instead of separate data and address lines. 

In one embodiment of the invention, the processor 913 is a microprocessor 
manufactured by Motorola, such as the 680X0 processor or a microprocessor manufactured 
by Intel, such as the 80X86, or Pentium processor, or a SPARC microprocessor from Sun 
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Microsystems, Inc. However, any other suitable microprocessor or microcomputer may be 
utilized. Main memory 915 is comprised of dynamic random access memory (DRAM). 
Video memory 914 is a dual-ported video random access memory. One port of the video 
memory 914 is coupled to video amplifier 916. The video amplifier 916 is used to drive the 
5 cathode ray tube (CRT) raster monitor 917. Video amphfier 916 is well known in the art and 
may be implemented by any suitable apparatus. This circuitry converts pixel data stored in 
video memory 914 to a raster signal suitable for use by monitor 917. Monitor 917 is a type of 
monitor suitable for displaying graphic images. 

1 0 Computer 901 can send messages and receive data, including program code, through 

C3 

0 the network(s), network link 921, and conununication mterface 920. Li the Internet example, 

lU 

remote server computer 926 might transmit a requested code for an application program 

ft 

through Internet 925, ISP 924, local network 922 and conrniunication interface 920. The 

w- 

1^ received code may be executed by processor 913 as it is received, and/or stored in mass 

1 y 

15 storage 912, or other non-volatile storage for later execution. In this manner, computer 900 
C3 may obtain appHcation code in the form of a carrier wave. Altematively, remote server 

computer 926 may execute applications using processor 913, and utilize mass storage 912, 
and/or video memory 915. The results of the execution at server 926 are then transmitted 
through Intemet 925, ISP 924, local network 922, and communication interface 920. In this 
20 example, computer 901 performs only input and output functions. 

Application code may be embodied in any form of computer program product. A 
computer program product comprises a medium configured to store or transport computer 
readable code, or in which computer readable code may be embedded. Some examples of 
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computer program products are CD-ROM disks, ROM cards, floppy disks, magnetic tapes, 
computer hard drives, servers on a network, and carrier waves. 

The computer systems described above are for pmposes of example only. An 
5 embodiment of the invention may be implemented in any type of computer system or 
programming or processing environment. 

Figure 10 illustrates an example of an initial synchronization in which a cUent starts 
with a file, for example, "Status.html" and a server starts with a file, for example, 
"PseudoRegistry.java" inside a folder, for example, "src". At block 1000, a cUent makes a 
change, for example to add contents to file Status.html. At block 1010, the path of the chent 
change is verified, for example Status.html. At block 1020, a check is made to verify if the 
path has any sub-divisions. In the example, the chent makes addition to a file, which lies in 
the root directory of the chent, so there is no further sub-divisions. At block 1030, if the path 
has sub-divisions, then the extended path of the chent change is verified before going to 
block 1040, else at block 1040 the contents of the change are verified, for example <!doctype 
html public "-//w3c//dtd html [..]>. 

Next at block 1050, a server makes the corresponding changes based on the client 
20 changes, for example to add contents to src. At block 1060, the path of the server change is 
verified, for example src. At block 1070, a check is made to verify if the path has any sub- 
divisions. In the example src is a directory that contams file PseudoRegistry.java where the 
additions have to be made. At block 1080, if the path has sub-divisions, for example 
src/PseudoRegistry.java, then the extended path of the server change is verified before going 
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to block 1090, else at block 1090 the contents of the change are verified, for example 
<package com.sun.PortalSyncServer;impor [..]>. 

An example of a client's version of its *l3riefcase index tree" that is used to detect 
subsequent changes on its side after a synchronization operation described above may look 
like: 

Objects to check for changes(l): 
MappedContentlndex 
path=/tmp/mirror/ 
Contentlndex 
children(2): 
Contentlndex 
path=Status.html 

content signature: OAhokamqGRLOlalcS 

MappedContentlndex 

path=src 

content signature: rXARIRMIcOQmcxo4n6 

Contentlndex 

children(l): 

Contentlndex 

path=src/PseudoRegistry.java 
content signature: snMGfFSnaOlgqZV 
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It should be noted here that while /tmp/mirror/ is a container for objects that are in the 
partnership, the container itself is not in the p^ership. In other words, if the container gets 
renamed, then that change is not propagated to the other side. 

Since there are no conflicts, the server tree is identical to the client's tree, except for 
the path of the synchronized folder. An example of a server's version of its ^'briefcase index 
tree" as a result of subsequent changes on its side after a synchronization operation described 
above may look like: 

Objects to check for changes(l): 
MappedContentlndex 

path=/home/usemame/directoryname/ (for example, /home/john/master/) 

Contentlndex 

children(2): 

Contentlndex 

path=Status.html 

content signature: OAhokamqGRLOlalcS 

MappedContentlndex 

path=src 

content signature: rXARIRMIcOQmcxo4n6 

Contentlndex 

children(l): 

Contentlndex 

path=src/PseudoRegistry.java 
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content signature: snMGfFSnaOlgqZV 

There is another kind of synchronization report where only the changes are sent, not a 
full census of files/folders as in the synchronization process seen above. For example, if a 
chent edits the Status.html file, while a server deletes the PseudoRegistryjava file, then the 
Ghent's version of its "briefcase index tree" that is used to detect subsequent changes on its 
side after a synchronization operation described above may look like: 

Objects to check for changes(l): 
MappedContentLidex 
path=/tmp/mirror/ 
Contentlndex 
children(2): 
Contentlndex 
path=Status.html 
Contents(142) 

Content signature: U713Jns2PJGVwZ8R 
MappedContentLidex 

path^src 
ContentMdex 

Content signature: OOwsnMGfFSnaOlgqZ 

Since there are no conflicts, a server's version of its "briefcase index tree" that is used 
to detect subsequent changes on its side after a synchronization operation described above is 

similar to a cHent's version of its "briefcase index tree" except for the path of the 
synchronized folder, and may look like: 
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Objects to check for changes(l): 
MappedContentlndex 

path=/ home/usemame/directoryname/ (for example, /home/john/master/) 

Contentlndex 

children(2): 

Contentlndex 

path=Status.html 

Contents(142) 

Content signature: U713Jns2PJGVwZ8R 

MappedContentlndex 

path=src 
Contentlndex 

Content signature: OOwsnMGfFSnaOlgqZ 

Thus, a file tree conflict processor is described in conjunction with one or more 
specific embodiments. The embodiments of the present invention are defined by the 
following claims and their full scope of equivalents. 
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